Content delivery networks (CDNs) have greatly improved the way content is transferred across data networks such as the Internet. A CDN accelerates the delivery of content by reducing the distance that content travels in order to reach a destination. To do so, the CDN strategically locates surrogate origin servers, also referred to as caching servers or edge servers, at various points-of-presence (POPs) that are geographically proximate to large numbers of content consumers and the CDN utilizes a traffic management system to route requests for content hosted by the CDN to the edge server that can optimally deliver the requested content to the content consumer. Determination of the optimal edge server may be based on geographic proximity to the content consumer as well as other factors such as load, capacity, and responsiveness of the edge servers. The optimal edge server delivers the requested content to the content consumer in a manner that is more efficient than when origin servers of the content publisher deliver the requested content. For example, a CDN may locate edge servers in Los Angeles, Dallas, and New York. These edge servers may cache content that is published by a particular content publisher with an origin server in Miami. When a content consumer in San Francisco submits a request for the published content, the CDN will deliver the content from the Los Angeles edge server on behalf of the content publisher as opposed to the much greater distance that would be required when delivering the content from the origin server in Miami. In this manner, the CDN reduces the latency, jitter, and amount of buffering that is experienced by the content consumer. The CDN also allows the content publisher to offload infrastructure, configuration, and maintenance costs while still having the ability to rapidly scale resources as needed. Content publishers can therefore devote more time to the creation of content and less time to the creation of an infrastructure that delivers the created content to the content consumers.
As a result of these and other benefits, many different CDNs are in operation today. Edgecast, Akamai, Limelight, and CDNetworks are some examples of operating CDNs. Each of the CDNs today operates independently of one another. However, this independent operational model is less than ideal for the CDNs and the customers of the CDNs. The CDNs directly compete with one another to offer the same intrinsic services. To do so, the CDNs duplicate server capacity and infrastructure where other CDNs have already deployed server capacity and infrastructure. The independent operational model also affects customers because a first CDN may optimally deliver content to a first region and a second CDN may optimally deliver content to a second region and a customer operating in both the first and second regions is forced to choose between the two CDNs or is forced to incur additional costs in obtaining services of both CDNs.
CDN federation is advocated by EdgeCast Networks Inc. of Santa Monica, Calif. as a way to address these existing shortcomings and also as a way to provide dynamic CDN scalability, provide a larger global CDN footprint, and increase utilization of a CDN operator's server capacity by making some or all of that server capacity available to multiple CDN service providers who then, in turn, can realize advantages of a CDN without the need to develop the optimized software and without the need to deploy the infrastructure necessary for a CDN. It is envisioned that CDNs participating in the federation can exchange server capacity with one another such that CDNs with excess server capacity can avoid the sunk costs associated with server capacity going unused by selling that server capacity to CDNs that are in need of additional server capacity. The server capacity sold by a CDN seller can then be configured and used by a CDN buyer to serve assets for at least one of its customers. In this manner, a customer's asset can be served using server capacity of two or more independently operated CDNs. It is further envisioned that participants in the federation can continue to independently manage and operate their networks with minimal change required to participate in the federation.
The CDN interoperation envisioned for the federation introduces issues and complexities that are not readily addressable with existing systems of the federation participants. One such issue is how to uniquely identify assets of customers that have been deployed to server capacity of different federation participants as a result of capacity sharing. Even though each CDN can manage how assets for its customers are identified within its internal platform, once an asset is deployed from a first CDN to a second CDN, the identification used by the first CDN to identify the asset may conflict with the identification the second CDN uses to identify an asset for a different customer. Conflicting identification of different assets that are deployed to the same CDN can result in delivery of the wrong asset or failed delivery of the asset.
To enable the envisioned federation, systems and methods are needed to permit interoperation between the independently operated CDNs that participate in the federation. As part of the interoperation, systems and methods are needed to uniquely identify different assets that are deployed to server capacity of different federation participants.